home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1993 July / Internet Tools.iso / RockRidge / mail / mmdf / mmdf43_docs / review / p2 < prev    next >
Encoding:
Text File  |  1986-10-02  |  7.0 KB  |  148 lines
  1. .SH
  2. The MMDF Design
  3. .PP
  4. The MMDF system design has not changed fundamentally
  5. from the original design proposed and implemented for MMDFI.
  6. The design of MMDFI is covered in detail in the paper
  7. ``An Internetwork Memo Distribution Capability''.
  8. .FN
  9. D. Crocker, E. Szurkowski, and D. Farber,
  10. ``An Internetwork Memo Distribution Capability'', Datacom Conference,
  11. September 1979.
  12. .FE
  13. In this chapter, I will summarize the basic design and discuss
  14. those changes that have been made in MMDFII.
  15. .PP
  16. Mail software is normally classed into one of two groups.
  17. A user agent (UA) is a program
  18. that is responsible for providing a ``user friendly'' interface
  19. for reading or writing mail and converting to the canonical
  20. interface of the mail transfer agent as necessary.
  21. A mail transfer agent (MTA) is a program or system
  22. to which you or your user agent entrusts a message for delivery
  23. to someone else's user agent.
  24. There has been a great deal of confusion caused by people who
  25. fail to realize the difference between a mail transfer agent and 
  26. a user agent, or even that a difference exists!
  27. There is a wide variety of user agents which can be used with
  28. MMDF, and it is the responsibility of the use agent to provide a user interface.
  29. This separation of the functions of user agent and mail transfer
  30. agent has many advantages, not the least of which is that MMDF
  31. can support many different user interfaces with ease.
  32. Currently, there are at least five different interfaces available
  33. including the Rand MH system, V6 style mail, Berkeley's Mail (cap-mail),
  34. the Tenex-style Send and Msg programs, and Rmail (for UUCP).
  35. MMDF is a mail transfer agent.
  36. MMDF does not have, nor does it claim to have, a good ``user interface'';
  37. instead it has a good program (MTA-UA) interface.
  38. MMDF accepts messages for delivery either locally or to a remote
  39. site.  It attempts to verify the validity of the addresses at submission
  40. time to the extent possible given only a host table and a list of
  41. local addresses.  If accepted, it will continually try to resend the
  42. message until the retry time is exhausted at which time
  43. the message is returned to the sender.
  44. .PP
  45. The MMDF system can be thought of as two subsystems, responsible
  46. for mail submission and mail delivery, respectively.
  47. Between these two halves is the mail queue.
  48. The mail queue will be discussed later, but basically it stores each
  49. message as two files, an address list with some control information, and
  50. a separate file containing only the message text (header and body).
  51. .PP
  52. The submission half of the system consists mainly of one program,
  53. called ``\fBsubmit\fR'', which is responsible for enqueuing mail to be
  54. delivered.  As much verification as possible is performed on the
  55. message at
  56. submission time.
  57. For mail destined for the local machine, this means making sure the
  58. destination account exists, and that any local mailing list or aliases
  59. expand properly.
  60. For mail that has a non-local host specification, the \fBsubmit\fR
  61. process checks to see if it knows how to reach the specified host.
  62. Mail which for any reason is known to be undeliverable, is not accepted
  63. for delivery.
  64. \fBSubmit\fR is called by two types of processes.  The first group includes
  65. user agents such as the \fBsend\fR program.  The second group 
  66. comprises channel
  67. programs such as \fBrmail\fR
  68. .FN
  69. The \fBrmail\fR program (/bin/rmail) is
  70. invoked by uucp when delivering mail
  71. on your system.
  72. .FE
  73. which are interfacing to remote mail transfer agents.
  74. .PP
  75. The delivery portion of MMDF is represented by two main elements: the
  76. \fBdeliver\fR program which manages the queue, and
  77. the channel programs which handle the details of
  78. delivery to a specific network, host, or mail system.
  79. The \fBdeliver\fR program takes each message which is eligible to
  80. be delivered, and opens the appropriate address list.  For each address
  81. in the list, \fBdeliver\fR ensures that it is running the appropriate channel
  82. program and then passes the envelope information
  83. .FN
  84. The MMDF envelope information consists of the the
  85. return address, the destination addresses, some delivery options and
  86. a reference to the message text file.
  87. .FE
  88. to the channel.  A reference to the file containing the actual
  89. message text is passed to the
  90. channel program.  The channel decides how
  91. to deliver the message and sees to any necessary message reformatting
  92. that may be necessary (e.g. ``header munging'').
  93. .PP
  94. There is currently a variety of channels and the number is growing.
  95. The local channel handles delivery of messages to local addresses.
  96. The list channel is a special, somewhat incestuous, channel which acts
  97. the role of channel, receiving user agent, and sending user agent all
  98. in one.  The list channel resubmits mail back into the mail system
  99. by calling \fBsubmit\fR.
  100. This has several benefits that will be discussed later.
  101. .FN
  102. See the section on the list channel.
  103. .FE
  104. The SMTP channel delivers mail via TCP/IP connections using the SMTP
  105. protocol.
  106. .FN
  107. J. Postel, ``RFC821 - Simple Mail Transfer Protocol'', Network Information
  108. Center, SRI International, August 1982.
  109. .FE
  110. The phone channel uses the PhoneNet link-level protocol software
  111. developed at the University of Delaware for sending mail over
  112. dialup or hard-wired terminal lines.
  113. The NIFTP channel queues mail as files to be transferred using the
  114. NIFTP protocol used in the British research community.
  115. The UUCP channel is used to queue requests for transfer using UUCP.
  116. .PP
  117. Development of MMDFII was started about the same time that the Sendmail 
  118. mail transfer agent was being
  119. written by Eric Allman at Berkeley.
  120. Dave Crocker met with Eric on a number of occasions and was impressed
  121. by his work.
  122. Some elements of the Berkeley software were so useful that
  123. they inspired the development of similar facilities in MMDFII.
  124. Not the least of these was the runtime configuration file.
  125. It is now possible to configure the MMDF software totally from a
  126. single, ASCII-text-based configuration file.
  127. Unlike Sendmail's terse configuration syntax, MMDF uses much more
  128. verbose keyword/value pairing for configuration information.
  129. MMDFII can be configured either from compiled-in values, for fast startup,
  130. or totally from the text configuration file, or from any combination of the
  131. two.
  132. As a result of the fact that many values can be compiled-in, the usual
  133. MMDF tailoring file is one-tenth the size of
  134. a Sendmail tailoring file, and can be even smaller, even on a large relay site.
  135. The runtime configuration file is one of the most useful additions
  136. in MMDFII, especially for sites supporting more than one host,
  137. since one can now run the same binaries on all machines of the same type.
  138. Another Berkeley-inspired facility was the ability to have an alias
  139. file entry that forces a delivery to a file or pipe.
  140. While initially insecure, this facility has been made
  141. reliable by adding code to \fBsubmit\fR that knows when you are
  142. processing an alias file entry and when you are processing some
  143. other type of address.
  144. Simple ownership of the file containing the address was not considered
  145. sufficient protection since there are too many
  146. files left writable to the world that are owned by root or other
  147. privileged users.
  148.